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A REVIEW OF PROMIS® 
EXECUTIVE SUMMARY 
Canadian Centre for Justice Statistics 



The Canadian Centre for Justice Statistics was created as a result of the 1979 
National Project on Resource Coordination, The concept of the Centre was one of 
four options developed by the Project in seeking improved co-ordination of 
resources for justice information and statistics. It is the purpose of the Centre not 
only to oversee the collection of justice information and statistics, but also to 
assist various jurisdictions ip finding the most efficient means of collection. This 
review addresses the issues involved in establishing a Useful, cost-effective 
information system. It introduces the Prosecuter's Management Information 
System (PROMIS) marketed by INSLAW, Inc. and relates the PROMIS system to the 
issues raised. Finally, it draws conclusions about the implementation of software 
systems in general and of PROMIS in particular. 

July 2, 1984 
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I 1. INTRODUCTION 



1.1 A REVIEW OF PROMIS BACKGROUND 

The Technical Assistance Directorate of the Canadian Centre for Justice 
Statistics (CCJS) assists Canadian jurisdictions in implementing effective 
information systems to support the administration of justice and to potentially 
contribute to the collection of National Justice Statistics. One particular system 
for case-tracking, called the Prosecutor's Management Information System 
(PROMIS), has attracted wide interest in Canada^ In response to ah expressed 
interest on the part of Canadian jurisdictions In acquiring useful information 
systems, particularly PROMIS, the Centre has produced this Review of PROMIS . 
The review is a plain-language report which attempts to cover the issues involved 
in selecting information system software for a particular jurisdiction, with a 
special focus on PROMIS. 

1.2 RESOURCES CONSULTED 

The resources consulted during the production of the Review of PROMIS 
included the following persons: 

0 Denis Sauvd, Technical Assistance Directorate, CCJS 

0 Arnold Wytenburg, Technical Assistance Directorate, CCJS 

a Stephen Chase, Research and Planning Branch, New Brunswick 
Pepartment of Justice 

0 Allan Gpodz, Manitoba Department of the Attorney General 

0 Jim Roberts, Planning, Research and Development, Alberta Attorney 
General 

o Gene Spencer, Court Services, British Columbia Ministry of the Attorney 
: General ' 

o IN5LAW Inc., author and publisher of the PROMIS technology, 
Washington, D.C. 20005 
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1.3 PURPOSE AND USES OF THIS REVIEW 




It is the purpose of this review to assist Canadian jurisdictions in selecting an 
automated justice information system. This review does not advocate one system 
over another, but rather attempts to identify and describe the role and impact of 
information systems in court administration, the issues involved in choosing a 
justice-related information system, and some of the choices available. 

Section 2 describes in detail the role of automated justice information 
systems, the issues involved in automating the court functions, and the necessary 
steps in choosing a system. 

Section 3 gives an overview of the Prosecutor's Management Information 
System (PROMIS), which has attracted wide interest in Canada. The section 
describes PROMIS in detail, and summarizes the experiences of the Canadian 
jurisdictions which have studied and/or installed PROMIS. 

Section 4 outlines the points to consider when making the decision to buy or to 
build a justice-related information system. The advantages and disadvantages of 
buying and building are identified, described, and compared. 

Section 5 compares the benefits and drawbacks of PROMIS, and summarizes 
the general experiences of the Canadian jurisdictions which have installed PROMIS. 

If further information is desired, please contact; 

Technical Assistance Directorate 

Canadian Centre for Justice Statistics 

19th Floor 

R.H. Coats Building 

Statistics Canada 

Ottawa, Ontario 

KIA 0T6 

(613) 993-7137 

X-..- ' . ' 
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2. INFORMATION SYSTEMS IN COURT ADMINISTRATION 

^ 1 

2.1 TYPES OF INFORMATION 

As in any organization today, court administrators are under pressure to 
collect, process, and report increasing volumes of information.! Two main 
categories of information are involved:2 

o administrative, and 
0 case-related. 

"Administrative" is meant to include all information pertinent to the operation 
of the court as a business. The administrative system comprises logistics and 
facilities management, pefsonhei management, and budgeting arid accounting. 

"Case-related" covers information pertaining to the issues and individuals who 
come before the court* This report is principally concerned with "case-related" 
information. The case-related system consists of four components; case 
management and clerical information; case-related information; integrated 
application processing procedures; and an interrelated data base. The case-related 
system can be used for four general activities; transactions; operational control; 
management control; and Strategic planning* 



2.2 THE PROBLEM OF DIVERSITY 

'■-O'- 

Individual jurisdictions frequently differ in their approach to gathering and 
processing case-related information. There are differences in legal procedures, 
court organization, staff capacity, arid management style. Specific dissimilarities 
exist in such areas as caseloads, statistics, arrest data, disposition data. 

Operational costs, application of the system by district offices, resources, and local 
statutory constraints. 
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The diversity in-;case management procedures makes it difficult to buy a 
quickly-installed, automated, "generic" information management system. While 
automated systems exist v/hich have the potential for satisfying each court's needs, 
no currently-existing system can be installed without at least some modifipations. 
These modifications may Significantly increase the actual cost of transferring to 
far above the expected cost. 



2.3 DEDICATED AND INTEGRATED SYSTEMS 

A major factor to consider when evaluating an automated justice information 
system is the extent to which the system automates the flow of information 
between the various court components. A dedicated system allows only one 
component of the court direct access to the data base, while an integrated system 
allows multiple components of the court to share the same data base. 



2.4 REQUIREMENTS ANALYSIS 

A requirements analysis should always be undertaken as part of any system 
development effort. The analysis should document the host environment as it truly 
exists, rather than the perceived ideal pattern. Studies of systems of all types 
have repeatedly indicated that satisfaction with a system's usefulness has less to do 
with the particular system selected than with how well the system matches the 
documented needs of the user. Even custom-built systems can fall short Of an ideal 
if the system designer does not carefully study the working environment which the 
system is meant to serve. 




2.5 THE CHOICES AVAILABLE 

if 

Buy an Existing S;^stem 

In 1979 and 1980, in separate surveys, the since-dissolved National Work Group 
on Justice Information and Statistics (Canada) and the National Evaluation 
Program (U.S.) examined a number of existing automated justice information 
systems available in Canada and the United States.3,4 of these systems, only 
PROMIS from INSLAW, Inc. was directly applicable to the top-priority operational 
and statistical needs expressed by the majority of jurisdictions. At present, only 
the most superficial information is available about specific existing systems other 
than PROMIS which may be transferable to other jurisdictions. 



Build a Customized System 

Building a customized system holds many advantages for the end user. The 
information being captured, stored and retrieved, the flow of work through the 
system, the format of reports and fornis can all be developed to fit the user's 
requirements exactly. The end product can conform precisely to the specified 
requirements, and the potential for high u.^'^^-^stisfaction is excellent. 



2.6 MAKING A CHOICE 

Transferring an existing system is attractive because of the perceived 
potential for savings in time and cost. However, research has shown that the 
transfer of an existing Justice information system may not result in lower costs.5 
While the cost of a system is an important factor, the decision between buying and 
building a software system cannot be based on financial criteria alone. Obtaining 
value for the money spent is harder to quantify, but vastly more important. An 
inexpensive system that is difficult to use can actually cost far more than a system 
whose larger price tag can be justified by its ability to provide high user 
satisfaction. Then again, high cost is not necessarily indicative of high quality. 




An integrated system, with a shared data base, is potentially the most 
effective type of system. In a shared data base, data is captured and stored only 
once whenever possible, thereby avoiding duplication of effort, redundancy of data, 
and the potential for errors of inconsistency. Security and access constraints can ' 
be installed so that each agency can access only the information to which it is 
entitled. These agencies are therefore assured of data privacy and integrity. 

The only truly useful measure of a system's potential performance is how well 
it accommodates the specific needs of its day-to-day users. User satisfaction 
generally has less to do with the choice between buying or building than with the 
matching of the actual needs of the user community to the final product. The most 
important tool used to make the decision is the detailed requirements analysis. 
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2. Information Systems in Court Administration 



Notes 



1. National Center for State Courts. Court Case Management lnfnrm.Hn„ 
Systems Manual , p. 15. 

2. Ibid., pp. 24, 25. 

3. T. Hutton, mG Document No. 7; J\n Overview of PRQMT.q (Nationai Work 
Group on Justice Information and Statistics, March 1981). 

4. Sidney H. Brounsteln et al, National Evaluation Program Phase 1 Summary 
Re port; Prosecution Management Inform a tion Systems (October 1980), p. 39. 

5. Ibid., pp. 60, 104. 






3. PROSECUTOR'S MANAGEMENT INFORMATION SYSTEM (PROMIS) 

3.1 THE PRODUCT AND THE VENDOR 

The Prosecutor's Management Information System (PROMIS) was originally 
developed in 1971 by the Institute for Law and Social Research (INSLAW) as a tool 
for prosecutors in the United States. The work was undertaken for the U.S. 
Attorney for the District of Columbia and was funded with grants from the U.S. 
Law Enforcement Administration Agency (LEAA). 

The first commercially available version of PROMIS was a batch processing 
PDP-11 mihicomputer-based system known as "Mini-PROMIS." Subsequently, 
PROMIS was redesigned and implerrcented on other equipment. Over the following 
decade, development and= enhancement of the software resulted in the availability 
of several improved versions of the system. 



This report deals primarily with PROMIS B 2 TM (hereafter referred to as 
PROMIS), art on-line version of PROMIS developed to operate on various popular 
mainframe and mini-computers. PROMIS is also marketed in several forms for a 
range of criminal justice ageneiesi Variations of PROMIS include DOCKETRAC, 
JAILTRAC, YOUTHJRAC, REGULAW, CASETRAC, CIVILTRAC and MODULAW. 



Capabilities 



PROMIS is designed to assist the prosecutor's office in tracking arrests, cases, 
defendants, and witnesses through the events In the criminal justice process. 
PROMIS consists of a data management system and a tailoring package which 
allows the system to be adapted, up to a point, to meet the specific needs of users 



in individual jurisdictionsi Transactions are entered on-line from a video display 
workstation. Reports can be printed from stored data through either on-line or 



batch requests. Statistical reports can also be generated in a variety of 
arrangements. 



The PROMIS software is designed to be fiexibie and readily adaptabie to the 
user’s needs and operational procedures. The software consists of a number of 
components (such as the Tailoring component, the Data Entry and Retrieval ' 

component, and the Historical Purge component), which may be Implemented 
selectivsly by th© user. 



Applications 



The principal services which PROMIS can provide to 



a court administrator are; 



• retrieval services - quickly locating information concerning 

special cases, offenses, charges, witnesses, defendants, and/or aftorne'y'si 



one or more 



s ch e duling services - either recording or retrieving scheduling 
information; 



c^ncal services - producing printed notices, subpoenas and 
labels; 



case jacket 



management services —printing reports about individuals or cases as 

background to court management decisions; 

re cord keeping services - maintaining records in such a way that 
statistics can be easily extracted. 



Hardware Releases 



As of July 2, 1984, hardware brands for which separate PROMIS versions exist 
mclude Burroughs, DEC. IBM, PRIME, and Wang. This gives potential PROMIS 
users who have not yet acquired hardware a degree of choice among hardware 
sup^ters. However, the experience of users who already own/share hardware. not 
on this list has indicated that converting an existing version for different ‘ 

equipment is time-consuming and costly. 




Software Availability and Cost 

INSLAW provides PROMIS software programs under Ucence initially for a 5- 

year term at a price of $65,000 (US.), as at July 2, 1984. 

The licence agreement includes the right to use one copy of the licenced 
software and delivery of the software documentation. At the expiry of the initial 
licence period, the client may renew the licence for another 5-year period 
(obtaining the most current software version for the new term) at 80% of the then- 

current 5-year feej or, the user can choose to renew the licence on his existing 
software for 30 years at a price of $30,000 (U.S.). 

The agreement also Includes a total of 10 days of training for one system 
manager, one system operator, the data entry operators, and the end users, and 
maintenance for the first year of the term of the licence agreement. Maintenance 
for subsequent years can be purchased separately at the per annum rate in effect 

at each annual renewal ($12,500 (US.) as at July 2, 1984). 



Vendor Support 



INSLAW does not directly implement the PROMIS system, but the company 
will assist in any way possible to ensure successful implementation and operation of 
the system. These services are not part of the licence agreement and must be 
negotiated separately. Services which JNSLAW has provided in the past include 
analysis of the costa and benefits of implementing PROMIS, requirements analyses, 
customization of packages to user specifications, installation of tb#package on the 

Client's hardware, operational support, and preparation of the user man^ 

INSLAW can provide technical assistance to prepare project descriptions, briefings, 
requests for consultant services or computer hardware procurement, software 
knowledge, and so on. 

INSLAW organizes and administers a PROMIS User Group in the United States 
that meets periodically in cities where a PROMIS system is installed. The users in 
the group trade knowledge and experience related to PROMIS in various 
environments. 




Most of INSLAW's current clients have indicated that the on-going advice and* 
support they have received was most helpful. These support services may be 
billable or non-billable, depending on the particular licence agreement or 
maintenance agreement in force, as well as on the nature of the problem* Both 
telephone consultation and on-site assistance may be obtained. 

Software Jransferability 

The licence agreement contains a standard clause prohibiting distribution or 
use of licenced software (including the tailored end product) to/by third parties. 

The agreement also prohibits unauthorized transfer of the system to a second 
installation within the particular jurisdiction. Permission to install PROMIS on 
multiple installations involves negotiation of separate licence agreements. 

3.2 PROMIS IN THE UNITED STATES 

A studyl conducted in 1980 in the United States found that among a sample of 
criminal justice offices with 25 or more employees who were currently using a 
computerized information system, 37 per cent were using some version of PROMIS, 
Of those offices planning such a system, 70 per cent were planning to use some 
version of PROMIS. < ; 

f\ 

The study did not find that PROMIS systems cost less than custom-built 
systems; in fact, on average, PROMIS-based systems cost about $25,000 (U.S.) or 
16.7% more to develop. However, in operation, PROMIS systems tended to cost a 
few cents less per Case, pn average. These statistics are based on the technology 
of the day (1980). 

The study indicated that user satisfaction with an individual system had less 
relationship to the type of system implemented than to how thoroughly the user’s 
requirements had been defined before the decision to buy or to build had been 
made. Even then» PROMIS systems tended to score slightly higher in user 
satisfaction, a fact that could be attributed to PROMIS User GrdUp meetings. 
Groups who built their own customized systems had no one with whom to share 
problems and/or achievements. 





3.3 PROMIS IN CANADA 

In Canada, the National Work Group on Justice Information and Statistics 
(NWG) and four provincial jurisdictions have evaluated PROMIS. The NWG 
installed PROMIS to study the possibilities of adapting the system to Canadian 
jurisdictions. Independently from the NWG study, three provinces (New Brunswick, 
Manitoba, and Alberta) evaluated and selected PROMIS; the fourth province 
(British Columbia) decided against selecting the system. 

The NWG study, and the provincial evaluations (which were requested by CCJS 
for this report), indicate the extent to which PROMIS meets the vendor's claims 
and the users' expectations when installed in Canadian jurisdictions. 

National Work Group on Justice Information and Statistics 

The National Work Group on Justice Information and Statistics (NWG) chose 
PROMIS as a test system because it was designed for installation in any 
jurisdiction, and because PROMIS met the major stated priority (development of 
more effective operational and statistical programs in the adult court areas) of the 
majority of the provincial and territorial jurisdictions. 

The evaluation of the system was complicated by the fact that the hardware 
v/hich supported PROMIS was not readily available. Following resolution of the 
difficulties caused by software/hardware incompatibility, the NWG found that the 
most difficult implementation task was tailoring for the particular jurisdiction. 

The tailoring package was not user-friendly, and required expert knowledge both of 
PROMIS and the jurisdictions's requirements. Even when expert knowledge was 
available, the task was lengthy and took several trials to complete. 



The NWG found that PROMIS could be adapted for Canadian jurisdictions. If 
an INSLAW-supported hardware/software configuration was not used, the 
installation and tailoring were both more difficult and time-consuming. The NWG 
recommended that, from the outset of the project, the jurisdiction have a manager 
who both understood PROMIS' concepts, and was reasonably familiar with the 
methods of the jurisdiction and with data-processing concepts in general. 




The NWG found that the on-line data entry and retrieval facilities were 
powerful and relatively easy to use. The security features, such ns terminal 
identifiers, passwords, and user identifiers, were adequate and were considered 

practical in the on-line environment. 

New Brunswick 

In New Brunswick, PROMIS plays a part in an overall Justice Information 
System (JIS). The aim of the JIS is to improve court management, while reducing 
expenditure on day-to-day operations. Custom-building was rejected as unfeasible; 
anfJ, of pre-packaged software, only PROMIS met the technical requirements of the 
project. However, adapting PROMIS for the UNIVAC 1100/83 hardware available 
in New Brunswick (a system not supported by INSLAW) proved to be more complex, 
time-consuming and costly than anticipated. 

Operationally, the PROMIS software has performed as expected. Th/?re are 
on-going problems with response time and turnaround time for ad hocVeports, but 
these seem to be linked with problems specific to the implementation, which are 
still being resolved. 



Manitoba 

i ; Manitoba chose PROMIS to fill its need for a Manitoba Justice Information 

f ; System (MJIS) in Winnipeg, The aim of MJIS is to Improve court management 

; , activities and to reduce expenditure on operational effort, It is hoped that MJIS 

^ will integrate the functions performed by the Winnipeg City Police, the Winnipeg 

5 Remand Centre* the Court Services and Criminal Prosecutions Divisions of the 

j ■ Department Of the Attorney General, Probations Services, and the Department of 

It Corrections. 

t'r V ■ 

i 
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As in New Brunswick, development of a custom system was rejected. for 
various reasons. PROMIS was selected as the only pre-packaged solution which 
met the project requirements. Although implementation is not yet complete, there 
seem to be few problems establishing the software In the IBM hardware 
environment (INSLAW supported). Tailoring of the software for the court system 
in Manitoba has not been smooth, but the problems have not been impossible to 
overcome, simply more costly and time-consuming, than originally anticipated. 

Alberta 

PROMIS was installed in Alberta as an interim measure to assist the Office of 
the Crown Prosecutor in Edmonton and Calgary. Eventually, the functions 
performed in these offices were meant to be incorporated into a Courts 
Automation Project (CAP). Due to the interim nature of the project, PROMIS was 
chosen as a relatively low-cost, pre-packaged, adaptable solution which was 
perceived to have been installed successfully in other (non-Canadian) jurisdictions. 

At the time the system was acquired, no IBM hardware release existed* so the 
then-current PDP-11/70 release was converted. This approach was both costly and 
time consuming; however, tailoring the software for use In the Canadian justice 
system was not very difficult. More important was the fact that manual 
procedures became more complex to accommodate PROMIS, and consequently 
users find the system to be cumbersome, "unfriendly", and Ineffective. 

It appears that many of Alberta's problems with PROMIS can be attributed to 
the lack of a formal study of user needs prior to implementation. A review Of the 
volumes of data captured has indicated that the system is required to operate 
beyond the limits for which it was intended. . 
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British Columbia 

Unlike the three previously-discussed jurisdictions, British Columbia had 
previously developed a series of automated systems to assist various functional 
components of the judicial process. Both PROMIS and a custom-built system would 
be capable of satisfying the technical requirements of an integrated system. 
However, upon examining PROMIS implementations and custom-buiit systems In 
other jurisdictions, British Columbia concluded that the expenditure required for 
implementation could be better used to upgrade existing systems and develop new 
custom-built systems. 



Summary 

The research by CCJS indicates that several general conclusions may be drawn 
from the PROMIS installations in Canada. 

Jurisdictions which have implemented PROMIS generally found that technical 
expertise far in excess of what had been originally anticipated was necessary for 
successful implementation of their projects. Implementation was faster and 
smoother on systems with a hardware environment that was already supported by 
INSLAW. All jurisdictions felt that communication with other Canadian users to 

share expertise and experience would have been valuable. 

All jurisdictions felt that system operating costs and the turnaround time in ad 
hoc reporting were higher than they should be. However, no adequate solution to 
either of these problems has yet been found. " 

^ ' ■ O'"' 

Some jurisdictions have expressed concern that PROMIS is fiot user-friendly, 
and PROMIS does not easily handle the volume of data encountered in the host 
Ganailian jurisdictions. 

, ' / ,, 0 , 

All jurisdictions felt that PROMIS performs as advertised by INSLAW, and that 

PROMIS met the overall user and technical requirements. 
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3. I^roaeci^tor's Management Information System (PROMIS) 

Notes 

1. Sidney H. Brounstein et al., j^jajional Evaluation Program Phase I Summary 
^gport; Prosecution Ma nagement Information Systems (October 1980), p. 23. 



‘J 
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4. BUY OR BUILD? 



There are Qencrelly two methods of acquiring applicatibns softwares buy a 
pre-packaged commercial system, or build a custom system. 

Pre-packaged applicatiomsys terns are one of the major growth areas in 
commercial computing today, v 'or standard applications such as payroll and 
accounting, a variety of generic packages can be purchased off-the-shelf and 
installed with little or no modification. Because the same package is used by many 
organizations, each purchaser pays for only a small proportion of the total 
development cost. For standard applications, it is frequently cheaper and faster to 
buy a package than to develop a custom-built system with the same capabilities. 

On the other hand, if the application is unique, or in low demand, there may 
not be a pre-packaged system available commercially. If the organization owns 
hardware that is non-standard in configuration, an existing software package may 
not fit that specific configuration. If the organization uses a procedure or method 
which is not reproduced in the software package, the procedure must be changed to 
conform to the pre-packaged software; the software must be modified; or a custom 
package must be developed to handle that procedure. 

A major factor in software evaluation is the determination whether a pre- 
packaged system (if available) is suitable for the application, or if a custom- 
designed system will provide a greater return for each dollar spent. This section 
discusses the issues involved in choosing to buy or build a software system, end 
Comperes the alternatives. This section does not attempt to advocate buying over 
building or vice versa, but rather to Indicate the factors which must be weighed in 
reaching a decision, 

A tabular comparison of the factors to be considered is presented in 
Table 4-A: Comparison of Factors in Buying and Building a Software System. 
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Table 4-A: Comparison of Factors in Buying and 
Building a Software System 



FACTOR 



BUYING A SYSTEM 



BUILDING A SYSTEM 



Conformity to 
User's Needs 



Software will usually require 
some modifications to adapt 
it to the hardware 
environment or to the 
organization's policies and 
procedures. 

Alternatively, departmental 
policies and procedures may 
require extensive 
modifications to adapt to the 
software. 



Specifications can be 
designed to meet the user's 
needs perfectly. 



Implementation 

Period 



Generally (but not always) 
short. Benefits of using the 
system can accrue quickly . 



Generally (but not always) 
longer than the 
implemehtatibn period for 
buying. loitial benefits may 
not accrue quickly. 

However, the custom-built 
software should be more 
efficient than a purchased 
system in terms of operating 
speed; when the system 
becomes operational, the 
benefits of increased speed- 
(lower operating costs and 
faster turh-ardund time) can 
accrue quickly. 



Implementation 

Schedule 



If extensive modifications 
are required, the 
implementation schedule may 
take more time than 
anticipated. 



The system can be built in 
stages to meet pressing heeds 
first, then expand to 
encompass the lower-priority 
needs. 



•continued 
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FACTOR 


BUYING A SYSTEM 


BUILDING A SYSTEM 


Contract 

Obligations 


The contract must specify 
the ownership and licensing 
of the package, any 
provisions for back-up copies, 
modifications, installation on 
multiple systems, and 
external support after 
acceptance of the product. 


If the work is performed by 
an independent software 
development company, the 
contract must specify the 
ownership and licensing of 
the package, any provisions 
for back-up copies, 
modifications, installation on 
multiple systems, and 
external support after 
acceptance of the product. 


Modifications 


The contract may restrict or 
prohibit modifications to the 
software, 


There are no restrictions on 
the modifications to the 
spftware. 




If the vendor subsequently 
updates the software, the 
modifications to the original 
version may be lost. 




Expansion 


The package may hot be 
expaiioable enough to fit the 
future needs of the users. 


With forethought and 
planning, the system can be 
continually updated and 
modified. 


Transferability 


The contract may restrict or 
prohibit installation of the 
software on other computer 
environments belonging to 
the purchaser. 


On a well-planned system, 
there are no legal constraints 
on the transferability of the 
software. 


Uniformity 

( 7 . 


If several agencies obtain the 
same package, a potential 
will exist for uniform 
information and statistics 
exchange among those 
agencies. 


Generally, each branch of the 
organization will receive the 
same system, thereby 
ensuring uniform information 
and statistics exchange. 






...continued 
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FACTOR 


BUYING A SYSTEM 


BUILDING A SYSTEM 


Age of System 


Older system has proven 
itself; newer system may not 
be sufficiently debugged. 


New custom-built system 
may not be completely tested 
and debugged. 




Older system frequently do 
not take advantage of the 
state-of-“the-art technology. 


New custom-built system can 
take advantage of the state- 
of-the-art technology. 


Design and 
Compatibility 


Because the vendor has 
internal expertise and 
experience with other users, 
the pre-packaged system may 
be more sophisticated than 
an internally-developed 
system. 

The system may not 
integrate with existing 
manual and automated 
procedures. 


The system can be designed 
to follow the organization's 
exact method of operation, 
and therefore integrates well 
with the existing manual and 
automated procedures. The 
system is likely to be more 
efficient operationally than a 
pre-packaged system. 


User's Group 


A number of users of the 
package may have organized 
a user's group. 


No user's group exists. 


Training 


Training provided by an 
experienced vendor may 
reduce the anxiety of staff 
members. However, training 
provided under contract may 
not be sufficient for the staff 
to make the most efficient 
use of the system. 


The training per|od may be 
shorter, because the program 
is designed to emulate the 
manual procedures used 
previously. However, the 
training provided may not be 
as extensive end professional 
as that provided by an 
experienced vendor. 






...continued 
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FACTOR 


BUYING A SYSTEM 


BUILDING A SYSTEM 


Staff 

Acceptance 


Those who operate and 
maintain the system may 
resent having to install, 
maintain, and use a system 
which was not developed 
internally. 


Staff members often develop 
pride of ownership in a 
custom-built system. 


Documentation 


Written documentation is 
more likely to be complete 
than on custom-built 
systems. 

If documentation is 
inadequate, the purchaser 
may have to buy or write 
additional documentation. 


A 

The documentation 
frequently will be incomplete 
and/or out-of-date. 

The documentation must be 
written, maintained, and 
Updated by the developers. 


b 

Development 

Cost 


The cost of the basic package 
is fixed and known. Usually, 
a pre-packaged system costs 
less than a custom-built 
system, because sales to 
several purchasers reduces 
the per capita development 
cost and subsequently the 
price per purchaser. 


The final cost of the project 
must be estimated. The time 
and resources required to 
develop the system are 
frequently underestimated. 




If extensive modifications 
are required, the cost may be 
much higher than 
anticipated. The time and 
cost required to modify and 
install the system are 
frequently underestimated. 




Operational 

Cost 


The operating costs may be 
estimated from the 
experience of other 
purchasers. 


The operating costs may be 
lower than those of a pre- 
packaged system, because 
the custom-built system can 
be developed for maxivTlum 
efficiency within the user's 
environment. Over a period 
of time, this lower operating 
cost may offset the higher 
development cost. f \ 
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4.1 CONCLUSIONS 

The question of whether to buy or to build an automated system may be 
answered only by considering many factors. The relative weight of each factor 
varies according to the specific needs of a particular organization at a given point 
in time. In a few cases, a commercial package will fit the user requirements 
exactly; in others, there will be no commercial packages available; in most cases, 
commercial software will fit some user requirements but not all of them. Given 
the latter case, the decision must be made to accept the limitations, to attempt to 
tailor the package, or to build from scratch. 

A requirements analysis should take into account each factor discussed in this 
section. This analysis must define the specifications of the system, determine if a 
pre-packaged system exists, estimate the costs . (of development, installation, and 
operation), and consider management factors such as the potential of the system 
for future growth and modification, and its impact on the user community. Only 
when the weight of all these factors in each particular situation is considered can , 
the buy/build qUestl^mbe resolved. ; 
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5. CONCLUSIONS 

Generally?,, the PROMIS software product can be adapted to suit the needs of 
the Canadian justice community. However, PROMIS' ability to satisfy the needs of 
a particular jurisdiction can only be determined by a careful evaluation of that 
jurisdiction's specific needs through a detailed requirements analysis. 

, ' f 

Only when all of the relevant factors have been defined and included in the 
overall cost/benefit equation can a clear distinction be made regarding the 
suitability of the PROMIS software to a specific jurisdiction. 



5.1 BENEFITS OF PROMIS 

PROMIS has a proven track record. The system has been installed in a number 
of American and Canadian jurisdictions with relative success. The vendor, 
INSLAW, provides comprehensive technical assistance (at varying cost) both before 
and after installation. The majority of the purchasers of the PROMIS software 
have been favourably impressed with the on-going support and advice recerved. 

The ability to tailor the product allows the user jurisdiction to modify the 
basic system to suit its particular needs. The data base, data entry screens and 
editing criteria, inquiry displays, indices, and output formats can all be modified or 
adapted to a greater or lesser extent. 






periodically in American cities. U/sers of the PROMIS system cap. trade 
experiences and knowledge related to PROMIS in various environments. 



In American justice-related automatiotvstudies, the PROMIS system tends to 
score slightly higher in user satisfaction than other systems. 



II 





5.2 DRAWBACKS OF PROMIS 

The user must convert, install, and tailor the software system. The conversion 
of PROMIS to a particular hardware environment (whether supported by INSLAW or 
not) requires skilled personnel who are khdwledgeable in PROMIS and subject- 
matter concepts, as well as in the policies and procedures of the jurisdiction. 
Without this expertise, conversion can take much longer than generally expected. 

PROMIS is not considered to be user-friendly. Existing policies and procedures 
may have to be modified to accommodate PROMIS. Data capture can be a 
complex and cumbersome procedure. In certain installations, terminal response 
time is slow. Although the system is thoroughly documented through the automatic 
generation of listings, end-user documentation must be written by the user. 

PROMIS is not capable of handling large volumes of data entry on a routine 
basis. 

Compared to custom-built systems, PROMIS systems do not necessarily cost 
less. An American study in 1980 (by Sidney H. Brounstein et al., for the National 
Evaluation Program) found that PROMIS systems cost, on average, about 16.7% 
more to buy, install, convertj and tailor. However, in the same study, PROMIS 
systems tended to cost slightly less to operate. 



5.3 SUMMARY 

The users who were most satisfied with the automated justice infortnation 
system (whether PROMIS-based or not) were those who matched the needs 
documented in a thorough requirements study to the system they eventually 
bought/developed. In any marketplace, the onus is on the buyer to shop wisely and 

select goods which fulfill a real need. Shopping for software is no exception to this 
rule. 












A REVIEW OF PROMIS® 
Canadian Centre for Justice Statistics 



The Canadian Centre for Justice Statistics was created as a result of the 1979 
National Project on Resource Coordination. The concept of the Centre was one of 
four options developed by the Project in ssekiny improved co-ordination of 
resources for justice information and statistics. It is the purpose of the Centre not 
only to oversee the collection of justice information and statistics, but also to 
assist various jurisdictions in finding the most efficient means of collection. This 
review addresses the issues involved in establishing a useful, cost-effective 
information system. It introduces the Prosecuter's Management Information 
System (PROMIS) marketed by INSLAW, Inc. and reLates the PROMIS system to the 
issues raised. Finally, it draws conclusions about the implementation of software 
systems in general and of PROMIS in particular. 
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1. INTRODUCTION 



1.1 A REVIEW OF PROMIS - BACKGROUND 

The Technical Assistance Directorate of the Canadian Centre for Justice 
Statistics (CCJS) assists Canadian jurisdictions in implementing effective 
information systems to support the administration of justice and to potentially 
contribute to the collection of National Justice Statistics. One particular system 
for case-tracking, called the Prosecutor's Management Information System 
(PROMls)j has attracted wide interest in Canada. In rasponse to an expressed 
Interest on the part of Canadian jurisdictions in acquiring useful information 
systems, particularly PROMIS, the Centre has produced this Review of PROMIS. 
The review is a plain-language report which attempts to cover the issues involved 
in selecting information system software for a particular jurisdiction, with a 
special focus on PROMIS. 



1.2 RESOURCES CONSULTED 

The resources consulted during the production of the Review of PROMIS 
included the following persons: 

0 Denis Sauvd, Technical Assistance Directorate, CCJS 

0 Arnold Wytenburg, Technical Assistance Directorate, CCJS 

0 Stephen Chase, Research and Planning Branch, New Brunswick 

Department of Justice 

o Allan Goodz, Manitoba Department of the Attorney General 
0 Jim Roberts, Planning, Research and Development, Alberta Attorney 

General 

o Spencer, Court Services, British Columbia Ministry of the Attorney 

General 

o INSLAW Inc., author and publisher of the PROMIS technology, 
Washington, D.C. 20005 




The principal publications used in preparing the review were: 

0 An Overview of On-Line PROMIS , INSLAW, Inc., Washington, D.C., 1978. 

° National Evaluation Program Phase I Summary Report; Prosecution 
Management Information Systems, Sidney H. Brounstein et al., October 
1980. 

° Court Case Management Information Systems Manual , National Center 
for State Courts. 

° NWG Document No.7; An Overview of PROMIS. T. Hutton, National Work 
Group on Justice Information and Statistics, March 1981. 

0 PROMIS for the Courts; A New Computerized Information System for 
Management of the Court . INSLAW, Inc., Washington, D.C., 1979 



o PROMIS 82 TM. Information Management and Decision Support for Public 
Prosecutors, INSLAW, Inc., Washington, D.C., 1982. 








1»3 PURPOSE AND USES OF THIS REVIEW 

It U the purpose of this review to assist Canadian jurisdictions in seiectinq an 
automated justice information system. This review does not advocate one system 
over another, but rather attempts to identify and describe the roie and impact of 
information systems in court administration, the issues invoived in choosing a 
justice-related information system, and some of the choices avaiiable. 

Section 2 describes in detaii the role of automated justice information 

systems, the issues involved in automating the court functions, and the necessary 
steps in choosing a system. 



Section 3 gives an overview of the Prosecutor's Management Information 
System (PROMIS), which has attracted wide interest in Canada. The section 
describes PROMIS in detail, and summarizes the experiences of the Canadian 
jurisdictions which have studied and/or installed PROMIS. 

Section 4 outlines the points to consider when making the decision to buy or to 
build a justice-related information system. The advantages and disadvantages of 
buying and building are identified, described, and compared. 

Section 5 compares the benefits and drawbacks of PROMIS, and summarizes 
the general experiences of the Canadian jurisdictions which have installed PROMIS. 

If further information is desired, please contact; 



Technical Assistance Directorate 

Canadian Centre for Justice Statistics 

19th Floor 

R.H. Coats Building 

Statistics Canada 

Ottawa, Ontario 

KIA 0T6 

(613) 993-7137 r, 




o 



2. INFORMATION SYSTEMS IN COURT ADMINISTRATION 




2.1 TYPES OF INFORMATION 

As in any orQ^nization todays court administrators are under pressure to 
collect, process, and report increasing volumes of information.! Two main 
categories of information are invplved:2 

“ administrative, and 

o case-related. 

''Administrative" is meant to include all information pertinent to the operation 
of the court as a business. The administrative system comprises logistics and 
facilities management, personnel management, and budgeting and accounting. 

"Case-related" covers information pertaining to the issues and individuals who 
coime before the court. This report is principally concerned with "case-related" 
information. The case-related system consists of four components: case 
management and clerical information; case-related information; integrated 
application processing procedures; and an interrelated data base. The case-related 
system can be used for four general activities; transactions; operational control; 
management control; and strategic planning. 



24 THE PROBLEM OF PIVERSITY^^^^^^^^^^^^^^^ ^ 

individual jurisdictions frequently differ in their approach to gathering and 
processing case-relotod information. There are differences in legal procedures, 
court organization, staff capacity, and management style. Specific dissimilarities 
exist in such areas as caseloads, statistics, arrest data, disposition data, 
operational costs, application of the system by district off ices, resources, and local 
statutory constraints. 
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The diversity in case management procedures makes it difficult to buy a 
, quickly-installed, automated, "generic" information management system. If case 
management was similar among Canadian jurisdictions, the courts could choose a 
common automated information management system and make mbdifioations in tho 
system to suit the specific needs of each province or territory. One advantage of 
similar systems would be the potentially lower cost of installing a common system 
} in each jurisdiction, compared to the cost of installing and modifying a different 
system in each jurisdiction. Also, as user experience with the common system 
expanded, the possibilities for sharing technical expertise would increase. 

I ' ‘ 

However, while automated systems exist which have the potential for 
satisfying each court's needs, no currently-existing system can be installed without 
at least some modifications.. Where computer hardware environments are not 
identical, the software system must be modified extensively during the transfer 
process. These modifications may significantly^;^m^ . 

transferring to far above the expected cost. For example* at least one study has 
found that, if an INSLAW-supported hardware/software cdnfiguration is not in 
place, the process of modifying PROMIS is much more time-consuming, costly, and 
cumbersome than expected.^ . 

When software has been installed and converted to run in a different hardware 
environment, the transfer process is not yet complete. The jurisdiction mdst either 
adapt to the system's formats, procedures, and structures (therefore changing its 
own), or modify the system to fit the jurisdiction. Generally, changing the 
jurisdiction's procedures is an expensive process; however, modifying the software 
I to fit the jurisdiction can also be as or more expensive if the software does not 
readily accommodate such efforts. 

I For similar reasons, software, systems custom-built for one jurisdiction are 
« seldom transferable to another without major modifications. If transfer is to be 
considered feasible at all, the system must be thoroughly documented. One of the 
largest obstacles to such transfers is Inadequate documentation. A survey in 1980 
in the United States concluded that apart from PROMIS installations, only five 
information systems surveyed had documentation that was considered adequate to 
support technology transfer.*^ 






t ] 
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2.3 DEDICATED AND INTEGRATED SYSTEMS 

A major factor to consider when evaluating an automated justice information 
system is the extent to which the system automates the flow of information 
between the various court components. 

In a dedicated system, only one component of the court has direct access to 
the data base. Some users believe they are best served by a system under their 
complete control. They believe that their data collection procedures are more 
reliable, and that maintenance and improvements can be carried out as needed. 

Integrated systems, which serve multiple components of the court who share 
the same data base, are potentially the most effective type of system. In a shared 
data base, data is captured and stored only once whenever possible; all reports of 

court-related activity and all inquiries against court-related data originate from 

the same data source. 

The chief differences between dedicated and integrated systems usually 
include; “ 

“ Information exchange — Dedicated systems perform functions for a single 
functional user only. Integrated systems allow centralized records to be 
updated as events occur throughout the system. New or changed 
information is available immediately to all system users. 

a Data recording — In a dedicated system, information is selected and / 

entered according to the needs and desires of a single user. In an 
integrated system, each User within the Court enters a selected portion of 
a complete set of information being collected. 

I V 

" Management information processing — A dedicated system can provide ' 

support which is limited to output which benefits the operation and 
management of a single user. An integrated system can provide support 
to the daily operation and management of all users within the court. ' 
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2.4 REQUIREMENTS ANALYSIS 



A requirements analysis should always be undertaken as part of any system 
development effort. The organizations which have been the most successful in 
developing and implementing a useful justice information system started with a 
thorough analysis of their requirements before making any decision about buying or 
building. 5 Organizations that decided to buy a particular system before defining 
requirements and resource constraints generally encountered avoidable problems in 
implementing the software. 

The analysis should document the host environment as it truly exists, rather 
than the perceived ideal pattern. This can only be done through careful study and 
with the co-operation and commitment of those who currently do the work. 

Studies of systems of all types have repeatedly indicated that satisfaction with a 
system's usefulness has less to do with the particular system selected than with 
how well the system matches the documented needs of the user. Even custom-built 
systems can fall short of an ideal if the system designer does not carefully study 
the working environment which the system is meant to serve. 

In 1979, a survey was made of 17 justice information system sites throughout 
the United States. The performance of a thorough requirements analysis was noted 
in only five sites (four non-PROMIS sites and one PROMIS site).^ The majority of 
the remaining projects failed to meet the users' expectations. 

Justice information systems (pre-packaged or custom-built) that were based on 
a systematic requirements analysis have tended to evolve in phases, with new 
applications being added to the system according to the conceptual design and a 
master plan. In these cases, realistic user expectations, based on clearly defined 
requirements, have been met.7 ' 






(i : ; ■ 

At present, only the most superficial information is available about existing 
systems (other than PROMIS) which may be transferable to other jurisdictions. The 
utility of such systems, and the amount of modification required to accommodate 
different operational environments and user requirements, can differ widely. Each 
system would have to be investigated independently. 

In 1979 and I960, in separate surveys, the since-dissolved National Work Group 
on Justice Information and Statistics (Canada) and the National Evaluation 
Program (U.S.) examined a number of existing automated justice information 
systems available in Canada and the United States.8,9 the systems which were 
examined in the two surveys include PROMIS-based systems, non-PROMIS 
integrated systems on large-scale computers, and non-PROMIS dedicated systems 
on minicomputers. See Appendix A for a list and short description of the systems 
which were examined. 

Of the existing systems examined by the studies referenced in this report, only 
PROMIS from INSLAW, Inc. was directly applicable to the top-priority operational 
and statistical needs expressed by the majority of jurisdictions. In 1980, PROMIS 
was the only commercial system known to be used in more than two jurisdictions. 
The only known non-PROMIS transferred system was CORPUS in Alameda County, 
California.iO 



2.5 THE CHOICES AVAILABLE 
Buy an Existing System 



Build a Customized System 

) 

Building a customized system holds many advantages for the end user. The 
information being captured, stored and retrieved, the flow of work through the 
system, the format of reports and forms can all be developed to fit the user's 
requirements exactly. The end product can conform precisely to the specified 
requirements, and the potential for high user satisfaction is excellent. 









Many jurisdictions, in both the United States and Canada, have built 
customized systems for court management. Except for PROMIS and CORPUS, all 
of the existing systems listed in Appendix A were originally custom-built for a 
particular jurisdiction. 

2.6 MAKING A CHOICE 
Cost 

'I ■ ' ■ ' 

I Transferring an existing system is attractive because of the perceived 

" j , . ■ • . 

' potential for savings in time and cost. However, research has shown that the 

I transfer of an existing justice information system may not result in lower costs.H 

i With many transferred systems, substantial investments in time and human 

> resources have been required to modify the software so that it runs in various 

i operational environments and adheres to the policies and procedures of the new 

I organization. Frequently, the time and effort required to study, test, evaluate, 

( modify, and debug an existing package have proven more costly than that required 

j to develop a custom-built package.J-2 ^ 

While the cost of a system is an important factor, the decision between buying 
and building a software system cannot be based on financial criteria alone. 
Obtaining value for the money spent is harder to quantify, but vastly more 
I important. An inexpensive system that is difficult to use can actually cost far 



more than a system whose larger price tag can be justified by its ability to provide 
high user satisfaction. Then again, high cost is not necessarily indicative of high, 
quality. 











Data Sharing in the Information System 

The most popular use for information systems is the production of case status 
reports and workload reports, followed by calendaring and scheduling.!? For these 
functions to work effectively, information must flow quickly and directly within 
and between the court components. To facilitate this flow of information, a shared 
data base within an integrated system is required. 

Because data is captured and stored only once whenever possible, a shared 
data base avoids duplication of effort, redundancy of data, and the potential for 
errors of inconsistency. Security and access constraints can be installed so that 
each agency can access only the information to which it is entitled. These 
agencies are therefore assured of data privacy and integrity. 

User Satisfaction 

The only truly useful measure of a system's potential performance is how well 
it accommodates the specific needs of its day-to-day users. User satisfaction 
generally has less to do with the choice between buying or building than with the 
matching of the actual needs of the user community to the final product. The most 
important tool used to make the decision is the detailed requirements analysis. 
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3. PROSECUTOR'S MANAGEMENT INFORMATION SYSTEM (PROMIS) 



3.1 THE PRODUCT AND THE VENDOR 

The Prosecutor's Management Information System (PROMIS) was originally 
developed in 1971 by the Institute for Law and Social Research (INSLAW) as a tool 
for prosecutors in the United States. The work was undertaken for the U.S. 
Attorney for the District of Columbia and was funded with grants from the U.S. 
Law Enforcement Administration Agency (LEAA). 



The first commercially available version of PROMIS was a batch processing 
PDP-11 minicomputer-based system known as "Mini-PROMIS." Subsequently, 
PROMIS was redesigned and implemented on other equipment. Over the following 
decade, development and enhancement of the software resulted in the availability 
of several improved versions of the system. 

This report deals primarily with PROMIS 82TM (hereafter referred to as 
PROMIS), an on-line version of PROMIS devel^iped to operate on various popular 
mainframe and mini-computers. PROMIS is a criminal case-tracking information 
management system that is used to automate the tracking of cases, defendants, 
and charges in the criminal justice process (local, state or provincial, and federal) 
within the prosecutor's office. 

■ — : .-i . 

Variations 

In addition to PROMIS 82, several vafiations of the software package are 
marketed for a range of criminal justice agencies. 



DOCKETRACTM is a trial court information system for civil and criminal 
environments. DOCKETRAC is used to automate scheduling and docketing 
functions, and to track cases, litigants, case parties, causes of action, and charges 
from filing to disposition. An optional Debt Collection module aids in the 
collection of fines and other debts. \\ 






JAILTRACTM is an on-line booking and jail management system that is used 
to automate the tracking of arrestees, inmates, and cases for law enforcement 
agencies, pretrial release agencies, and detention centers. 



YOUTHTRACTM is a justice information system which tracks the progress of 
each juvenile referral through final disposition. YOUTHTRAC reflects the 
terminology, processing procedures, and security and confidentiality requirements 

I that are specif ic to juvenile justice and child care agencies. 

' ■ 

REGULAWTM is a justice information system which assists regulatory and 
administrative law agencies in controlling and reporting on their workloads. 

■ ■ * ■ • ■ ' • ■ 

r CASETRAC^^ is a civil and criminal justice information system used in the 

complex litigation environment in state or provincial offices. CASETRACTM 

. . t 

! monitors the progress of cases through the preparation and litigation stages. An 

; optional Debt Collection module aids in the collection of fines and other data. 

CIVILTRACTM is a civil justice information system which records case 
documentation in test actions against state, provincial, or local jurisdictions. 

MODULAW^i^ is a justice information system designed for private law firms 
and corporate legal departments. MODULAW is used to support most areas of 

9,. • .... 

client and file management, including docket control and calendaring, conflict-of- 
! interest monitoring, and cross-referenced indexing of issues. 

Capabilities 

■■ ■ ■ 

PROMIS is designed to assist the prosecutor's office in tracking arrests, cases, 
defendants, and witnesses through the events in the criminal justice process. 
PROMIS consists of a data management system and a tailoring package which 
allows the system to be adapted, up to a point, to meet the specific needs of users 
' in individual jurisdictions. Using the 1 tailoring capability, users may customize the 

data base, data entry screens, data editing criteria, inquiry displays, indexes, and 
output formats. 
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Transactions (data entry, updating, and retrieval) are entered on-line from a 
video display workstation. Reports can be printed from stored data through either 
on-line or batch requests. Statistical reports can also be generated in a variety of 
arrangements. Terminal displays and printed reports can be tailored to fit the 
User's requirements. 

, ■ ; ; ■ a' ■ . . 

Components 

The PROMIS software is designed to be flexible and readily adaptable to the 
user's needs and operational procedures. The software features described below 
are provided as components of PROMIS. These components are standard features 
of the PROMIS package; however, the user may decide to implement them 
selectively. 

The Tailoring package permits the user to customize the software to suit the 
particular vocabulary, data structures, and data capture, update and retrieval 
functions of the host environment. 

The On-Line Data Entry and Retrieval feature is a data management system 
which allows information to be added to, modified, or deleted from the data base 
via on-line video display terminals. 

The Internal Data Base Manager controls access to and manages the internal 
functions of the data base. 

The Formatted Output Package enables the user to design and produce forms, 
special on-line inquiry screens, and reports. 

The Reports Package produces several types pf standardized reports, either on 
demand or at regularly scheduled times. The flexibility of the Reports Package 
enables the user to define a variety of descriptive and statistical reports to suit the 
specific needs of the user. 
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The Generalized Inquiry Package enables the user to produce descriptive data 
on any group of related cases or matters, in both the on-line and historical files. 
This package is designed as an aid to managerial decision-making or policy 
development. 

The Management Report Package enables the user to define and modify 
statistical reports. This package provides aggregate numerical information on any 
group of related cases or matters, in both the on-line and historical f iles. This 
package is designed as an aid to management decision-making or policy 
development. 

The Historical Purge feature removes certain records (on the basis of user- 
defined criteria) from the on-line master file to off-line (magnetic tape) historical 
files. Summary records may be retained in the on-line files. 

The Security functions ensure privacy and security for all files, by allowing the 
system manager to limit access to information in the data base. Access to the 
system can be limited by terminal location or by the operator, using defined 
passwords. The password and security systems may be periodically changed to 
maintain confidentiality. 

The system's back-up features, the Logging and Recovery features and the 
Recovery and Analyzer feature, ensure that back-up copies of the information in 
the data base are kept. Recovery features allow information to be recovered in 
the event of system failure. 

Applications 

PROMIS can provide the court administrator with services and benefits which 
can improve case management and office productivity. 

The system's retrieval features can locate information concerning one or more 
specific cases. PROMIS can provide access by multiple indexes, including case 
number, defendant number, name, calendar date, and type of offense. The system 
can conduct phonetic, as well as literal, name searches. 






The system's scheduling feature can automatically produce a case calendar 
which can also be used for recording case actions. The calendar provides summary 
case and defendant information, a list of completed events, and the next scf^eduled 
event, together with space to record the outcome of the case for subsequent data 
entry. 

The system's office administration features can produce printed notices, 
subpoenas and case jacket labels. The administrative documents can be produced 
on-line or in batch mode (which allows long documents or a large number of 
standard documents to be printed at night or at other non-peak hours). 

The system's management reporting features, the Management Report 
Package and the Centralized Inquiry Package, provide information about 
individuals or cases as background to long-term court planning decisions. The 
Management Report Package can provide aggregate information on each stage of 
the Judicial process; for example, the number of, and reasons for, rejections at 
screening or court dismissals; the number of guilty pleas to the top charge and to 
the reduced charge; bail statistics; and cases pending. The Generalized Inquiry 
Package can provide descriptive data on a group of cases with one or more features 
in common, such as type of crime, assigned prosecutor, assigned judge, and reason 
for dismissal. 

The system's record-keeping features maintain records in such a way that 
statistics can be extracted on request. The system can also assist the user in 
monitoring and recording the Information being added to the data base. 

The system's statistical reporting features tra$k the details regarding both 
defendants and cases through each step of the crinriinal justice process from arrest 
to finsl disposition. Statistics are available in numerous arrangements, for 
example, breakdowns by individual charges (e.g., robbery), or groups of charges 
(e.g., all offences or all violent crimes). The reports can display frequency counts 
and percentages, attrition rates, dispositions, and time delays, together with the 

recorded reasons for all actions taken. 
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The system's Historical Purge feature retires closed cases from on-line status 
(direct access through terminals) to an historical file (off-line storage medium). 
Through the tailoring package, the user can specify the criteria for retiring a case. 
If desired, a skeleton record of each closed case may remain in the on-line data 
ease. The generalized reporting feature can access both the current and historical 
files. ,, 



i Hardware Releases 

The on-line version of PROMIS is designed to operate on various mainframe 
computers or minicomputers. In fact, PROMIS was developed with the intention 
I that it be capable of installation on several of the more popular brands of computer 

hardware. 

■ '’'i ■ ■ , - ■ 

The process of making PROMIS software operational on the user's hardware is 

referred to as conversion. The conversion process may be fairly simple, or quite 

! long and arduous. The latter is likely to be the case if the user's brand of hardware 

is not one for which INSLAW has an existing software version, 

As of July 2, 1984, hardware brands for which separate PROMIS versions exist 
; include Burroughs, DEC, IBM, PRIME, and Wang. This gives potential PROMIS 

- i users who have not yet acquired hardware a degree of choice among hardware 

suppliers. However, the experience of users who already own/share hardware not 

on this list has indicated that converting an existing version for different 
equipment is time-consuming and costly. 

f Although a wide variety of terminals can be considered in the evaluation 

process, only one type may be selected for each PROMIS installation. The system 
does not tolerate a mixture of terminal types within a given installation. 
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Software Availability and Cost 



INSLAW provides PROMIS software programs under licence initially for a 5- 
year term at a price of $65,000 (U*S»)> as at July 2, 1984. 

The licence agreement includes the right to use one copy of the licenced 
software and delivery of the software documentation. At the expiry of the initial 
licence period, the client may renew the licence for another 5-year period 
(obtaining the most current software version for the new term) at 80% of the then- 
current 5-year fee; or, the user can choose to renew the licence on his existing 
software for 30 years at a price of $30,000 (U.S.). 



The agreement also includes a total of 10 days of training for one system 
manager, one system operator, the data entry operators, and the end users, and 
maintenance for the first year of the term of the licence agreement. Maintenance 
for subsequent years can be purchased separately at the per annum rate in effect 
at each annual renewal ($12,500 (U.S.) as at July 2, 1984). 



Vendor Support 






INSLAW does not directly implement the PROMIS system, but the company 
will assist in any way possible to ensure successful implementation and operation of 
the system. These services are not part of the licence agreement and must be 
negotiated separately. Services which INSLAW has provided in the past include 
analysis of the costs and benefits of implementing PROMIS, requirements analyses, 
customization of packages to User specif icationSr installation of the package on the 
client's hardware, operational support, and preparation of the User manual, 

INSLAW can provide technical assistance to prepare project descriptions, briefings, 
requests for consultant services or computer hardware procurement, software 
knowledge, and so on. 



INSLAW organizes and administers a PROMIS User Group in the United States 
that meets periodically in cities where a PROMIS system is installed. The users in 
the group trade knowledge and experience related to PROlyllS in various 
environments. 
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Most of INSLAW's current clients have indicated that the on-going advice and 
I support they have received was most helpful. These support services may be 

I billable or non-billable, depending on the particular licence agreement or 

I maintenance agreement in force, as well as on the nature of the problem. Both 

I telephone consultation and on-site assistance may be obtained. 

Software Transferability 

' • i ■ ■ 

. ■ . f 

! The licence agreement contains a standard clause prohibiting distribution or 

I use of licenced software (including the tailored end product) to/by third parties. 

! The agreement also prohibits unauthorized transfer of the system to a second 

! installation within the particular jurisdiction. Permission to install PROMIS on 

^ I multiple installations involves negotiation of separate licence agreements. 

j'. 

I 3.2 PROMIS IN THE UNITED STATES 

'I ■ 

i A study! conducted in 198D in the. United States found that among a sample of 

criminal justice offices with 25 or more employees who were currently using a 
computerized information system, 37 per cent were using some version of PROMIS. 

Of those offices planning such a system, 70 per cent Were planning to use some 
' version of PROMIS. 

The study did not find that PROMIS systems cost less than custom-built 
systems; in fact, on average, PROMIS-based systems cost about $25,000 (U.S.) or 
16.7% more to develop. However, in operation, PROMIS systems tended to cost a 
few cents less per case, on average. These statistics are based on the technology 
of the day (1980). ■ 



u 




The study indicated that user satisfaction with an individual system had less 
relationship to the type of system implemented than to how thoroughly the user's 
requirements had been defined before the decision to buy or to build had been 
made. Even then, PROMIS systems tended to score slightly higher in user 
satisfaction, a fact that could be attributed to PROMIS User Group meetings. 
Groups who built their own customized systems had no one with whom to share 
problems and/or achievements. 



3.3 PROMIS IN /CANADA 



In Canada, the National Work Group on Justice Information and Statistics 
(NWG) and four provincial jurisdictions have evaluated PROMIS. The NWG 
installed PROMIS to study the possibilities of adapting the system to Canadian 
jurisdictions. Independently from the NWG study, three provinces (New Brunswick, 
Manitoba, and Alberta) evaluated and selected PROMIS; the fourth province 

(British Columbia) decided against selecting the system* 

The NWG study, and the provincial evaluations (which were requested by GCJS 
for this report), indicate the extent to which PROMIS meets the vendor's claims 
and the users' expectations when installed in Canadian jurisdictions. 



National Work Group on Justice Information and Statistics 

The National Work Group on Justice Information and Statistics (NWG) began 
testing PROMIS as part of its mandate to help Canadian jurisdictions become 
aware of developed or planned automated justice information systems, and to 
provide technical assistance in adapting existing operational systems for Canadian 
jurisdictions. PROMIS was chosen as a test system, because it was designed for 
installation in any jurisdiction, and because PROMIS met the major stated priority 
(development of more effective operational and statistical programs in the adult 
court areas) of the majority of the provincial and territorial jurisdictions. 
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When the NWG tested PROMIS, its evaluation of the system was complicated 
by the fact that the hardware which supported PROMIS was not readily available. 
Following resolution of the difficulties caused by software/hardware 
incompatibility, the NWG found that the most difficult implementation task was 
tailoring for the particular jurisdiction. The tailoring package was not user- 
friendly, and required expert knowledge both of PROMIS and the Jurisdictions's 
requirements. Even when expert knowledge was available, the task was lengthy 
and took several trials to complete. 

The NWG found that PROMIS could be adapted for Canadian Jurisdictions. If 
an INSLAW-supported hardware/software configuration was not used, the 
installation and tailoring were both more difficult and time-consuming. The NWG 
recommended that, from the outset of the project, the Jurisdiction have a manager 
who both understood PROMIS' concepts, and was reasonably familiar with the 
methods of the Jurisdiction and with data-processing concepts in general. 

INSLAW provided two types of documentation for PROMIS. A set of manuals 
described the PROMIS system. In addition, each program had documentation 
embedded within it, and a utility program was provided to extract this 
documentation. The embedded documentation must be referenced frequently while 
the system is being tailored. 

The NWG found that some of the PROMIS features do not become clear until 
test cases are added to the data base and access is attempted in the on-line 
environment. 

The software delivered by INSLAW assumed that a particular type of terminal 
would be used With the system. The NWG recommended that the default terminal 
be used if it was economically feasible. If another type of terminal was to be used, 
the services of a telecommunications analyst would be required. 

The NWG found that the on-line data entry and retrieval facilities were 
powerful and relatively easy to use. The security features, such as terminal 
identifiers, passwords, and user identifiers, were adequate and were considered 
practical in the on-line environment. 
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New Brunswick 

In New Brunswick, PROMIS plays a part in an overall Justice Information 
System (JIS). The aim of the JIS is to improve court management, while reducing 
expenditure on day-to-day operations. The on-line system is installed in the 



fourteen court offices, with each office having at least one video display 
workstation and one hard-copy printer. Data entry is handled by the regional court 
staff within each office. Operational reports, forms, and documents are produced 
locally while the majority of the statistical and management reports are produced 
at the central office and are distributed accordingly. 



Custom-building was rejected as unfeasible; and, of pre-packaged software, 
only PROMIS met the technical requirements of the project. Major factors in the 
decision to select PROMIS were that the tailoring package provided fof future 
growth and change; INSLAW could support the product with technical information, 
documentation, training, and system enhancements; the package was available at 
no charge (note; this is no longer the case); and financial support for the 
implementation of PROMIS was available from the NWG. In addition, PROMIS 
was perceived to have been successfully implemented in Alberta and received a 
favourable review in a Manitoba feasibility study. 

Although the PROMIS package met or exceeded the technical requirements 
originally identified for the JIS project, adapting PROMIS for the UNIVAC 1100/83 
hardware available in New Brunswick (a system not supported by INSLAW) proved 
to be more complex, time-consuming and costly than anticipated. The single 
largest problem was the conversion of the software to the unsupported computer 
environment. 






The adaptation of PROMIS, an American package, to the Canadian 
environment was much simpler than anticipated due to the effective use of the 
tailoring subsystem. However, the level of in-house expertise necessary to install 
the software proved to be much higher than anticipated. This problem can be 
largely attributed to the environment not being supported by INSLAW. While 
extensive technical knowledge of both PROMIS and the New Brunswick 
environment was required during implementation, a simple working knowledge of 
the system proved to be sufficient for daily operation. 



The possibilities for sharing of technical expertise were non-existent, because 

no other PROMIS siystems had been installed on a UNIV AC system. The 

I: 

possibilities for s^/aring subject-matter expertise was restricted to other Canadian 
installations. In^fact, even this possibility was almost non-existent because only 
one such instajiation existed at the time (in Alberta), and the package had been 
installed at that location in a completely different context. 

PROMIS took approximately fifteen calendar months to install in New 
Brunswick, much longer than the expected three to six months. The conversion to 
the UNIVAC environment and the lack of available human resources were the 
major factors in the overrun. 

Support from INSLAW was often requested during the early stages of the 
project. On most occasions, the responses were both timely and effective. 
Throughout the project, INSLAW provided quality documentation (both system and 
training), and has continually upgraded and enhanced the PROMIS software. 

During the implementation and tailoring phases of the project, very little 
impact was felt by the users. To ease the transition of each local office from its 
unique operational procedures to the new, uniform procedures, the installation 
procedure was phased to bring one office on-line at a time. 

Operationally, the PROMIS software has performed as expected. There are 
on-going problems with response time and turnaround time for ad hoc reports, but 
these seem to be linked with problems specific to the implementation, which are 
still being resolved. Although the operational costs were originally high, a 
modified rate structure has improved this problem. Presently, the cost is not a 
major concern, but may be somewhat excessive when compared to other systems 
currently in use. The regularly scheduled reports produced by the system are 
generally correct and on schedule^ These reports require an overnight production 
run. The procedures for these reports were implemented by the Data Processing 
Division, not by the users. 




The system and data security have proven satisfactory to date. 

The Management Reporting Package, a standard component of PROMIS, has 
not yet been fully implemented. It is anticipated that the package will be 
implemented following the completion of testing, and will be used to improve the 
long-term planning of the courts. However, this is not as high in priority as the on- 
going problems with terminal response time and ad hoc report turnaround time. 

Maintenance on the system has been less difficult than originally anticipated, 
although the non-standard hardware environment requires regular attention. The 
cost of on-going maintenance has been estimated at approximatley one person-year 
per annum. 

In the management operations, the system meets the regular report schedule, 
but is slow in satisfying ad hoc report requests. In the future, user control over the 
report production may be implemented. 

Overall, implementation of the system is considered to be successful. As 
indicated, there are several on-going areas of concern and a detailed study has 
been initiated to identify causes and potential solutions. 

Manitoba 

Manitoba chose PROMIS to fill its need for a Manitoba Justice Information 
System (MJIS) in Winnipeg. The aim of MJIS is to improve court management 
activities and to reduce expenditure on operational effort. It is hoped that MJIS 
will integrate the functions performed by the Winnipeg City Police, the Winnipeg 
Remand Centre, the Court Services and Criminal Prosecutions Divisions of the 
Department of the Attorney General, Probations Services, and the Department of 
Corrections. It is intended that all locations will have video display workstations 
and, with the exception of the courtrooms, hard-copy printers for the production of 
forms, documents, and reports. 
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As in New Brunswick, development of a custom system was rejected for 
various reasons. PROMIS was selected as the only pre-packaged solution which 
met the project requirements. Major factors in the decision to select PROMIS 
were that INSLAW was prepared to provide adequate support throughout the 
implementation, the tailoring package provided for future growth and modification, 
the price was relatively low compared to custom development, and PROMIS was 
perceived to have undergone reasonably successful implementation in other 
jurisdictions. 

Although implementation is not yet complete, th'pre seem to be few problems 
establishing the software in the IBM hardware environment (INSLAW supported). 
Tailoring of the software for the court system in Manitoba has not been smooth, 
but the problems have not been impossible to overcome, simply more costly and 
time-consuming than originally anticipated. 

A solid technical background in PROMIS and the justice environment are 
considered to be essential requirements to successfully install the software. 
Although no definite conclusions can be reached yet, it is felt that a solid technical 
background in PROMIS will continue to be required to maintain effective 
performance levels in both operations and maintenance endeavours. 

As in New Brunswick, outside assistance and expertise relating specifically to 
Canada were ; dt available. The American installations that had been reviewed did 
not provide pertinent insights into implementation or technical aspects of the 
system. Some Canadian experience had been gained in Alberta, but its software 
was an earlier version and had been implemented to serve a much different 
purpose. 

Throughout the project, INSLAW has provided accurate, timely and effective 
support for the package and has continually upgraded and enhanced the product. 

The decision to consult INSLAW on technical points has saved time and money. 

Manitoba recommends that any jurisdiction anticipating the purchase of PROMIS 
should involve the, vendor as much as possible throughout the project's life cycle, to 
gain the maximum benefit from the vendor’s experience and expertise. 
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Because the MJIS is not an operational system, specific technical problems 
have not been identified. However, some areas of possible concern have been 
marked for future scrutiny. The terminal response time will be a critical concern 
when the system becomes operational, because terminals wUl be installed within 
the courtrooms. Problems with lack of "user-friendliness" are not anticipated; i 
however, these areas of concern wUl be monitored and addressed if necessary. 

The method of handling text has been identified as a general deficiency of the 
current version of PROMIS. Although PROMIS can handle textual data, the 
occasional need to maintain exact wording has led to the development of an 
auxiliary system which uses a word processor. 

The project is estimated to require fifteen calendar months from the start of 
the project to the final implementation. At the time of this report, the project 
was performing beyond the original estimates for human and dollar resource 
consumption and was extending beyond the original calendar schedule. 

Because the MJIS is not yet operational, the day-to-day and managerial 
operations have not been automated. The operational costs have not yet been 
determined, but the system is expected to provide service at relatively low cost. 

Although PROMIS is not yet operational in Manitoba, the product has 
performed as expected, and has fulfilled all its advertised specifications and most 
of the project's requirements. In the future, Manitoba hopes to integrate the MJIS 

with an automated accounting system and to expand the MJIS to include additional 
courts and cities. 
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Alberta 



PROMIS was installed in Alberta as an interim measure to assist the Office of 
the Crown Prosecutor in Edmonton and Calgary. Eventually, the functions ' 
performed in these offices were meant to be incorporated into a Courts 
Automation Project (CAP). Due to the interim nature of the project, PROMIS was 
chosen as a relatively low-cost, pre-packaged, adaptable solution which was 
perceived to have been installed successfully in other (non-Canadian) jurisdictions. 
The mainframe computer on which PROMIS runs serves two locations (Calgary and 
Edmonton) via nineteen video display workstations and fourteen printers. 

At the time the system was acquired, no IBM hardware release existed, so the 
then-current PDP-il/70 release was converted. This approach was both costly and 
time consuming. Although the conversion was originally perceived as a relatively 
straightforward and problem-free task, many difficulties were encountered. The 
conversion indicated that a high level of expertise related to PROMIS was 

necessary for successful conversion, installation, operation, and maintenance of the 
system. | 

Tailoring the software for use in the Canadian justice bystem was not very 
difficult. INSLAW had partially adapted PROMIS to accommodate Canadian 
terminology before the software was delivered. Alterations not handled by 
INSLAW were resolved in the conversion and installation process. 

At that time, little or no expertise with PROMIS existed in Canada and 
INSLAW did not support PROMIS in an IBM environment. In retrospect, Alberta 
feels that the ability to share PROMIS-related experiences with other Users would 
have been beneficial. ‘ 

INSLAW provided timely, accurate and helpful support during the conversion 
process, despite the disadvantages inherent with installing PROMIS on unsupported 
hardware. 
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The installation, conversion and tailoring of the system was accomplished 
within the allotted six-month time frame. This was achieved only at the expense 
of human and dollar resources significantly in excess of original estimates. The 
extensive resource overruns have been largely attributed to the complexity of 
installing the system on an unsupported hardware environment. 

At the time, several seemingly insignificant modifications to the existing 
systems and procedures were required during the installation and tailoring 
procedures. Manual procedures became more complex in order to accommodate 
PROMIS, and consequently users find the system to be cumbersome, "unfriendly", 
and ineffective. A modification which has had significant impact on the users was 
the change in responsibility for the production of subpoenas. This task was 
originally pesTormed by the Law Enforcement community, but is now performed by 
the Office of the Crown Prosecutor. 

Due to the short-term nature of the original project, Alberta decided not to 
implement several of the PROMIS options. Because Alberta's implementation of 
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the system lacked the Historical Purge function, the unchecked growth of the data 
files caused disk storage requirements, data retrieval cost, and performance to be 
adversely affected. As the lifetime of this system has been extended, an archiving 
function has been developed, and the resulting performance gains should result in 
reduced operating costs and some increase in user satisfaction. 

The Management Reporting Package was not implemented due to the 
temporary nature of the original project. If this package is implemented in the 
future, it is expected that the cost and difficulty of converting, interfacing and re- 
tailoring will be high. 



Very little system maintenance has been required. Generally, system "bugs" 
have been extremely scarce and routine maintenance has been simple, rarely 
required, and easily accomplished. 




Operationally, the system is slow and difficult to work with. The system does 
not easily handle large volumes of data entry on a routine basis. A large number of 

data entry screens must be used to capture a limited amount of data. The system^ 

lacks proper data-processing controls and contains only limited edit features. 

Users have complained that accessing and retrieving data requires excessive and 
time-consuming effort. 

It appears that many of Alberta's problems with PROMIS can be attributed to 
the lack of a formal study of user needs prior to implementation. A review of the 

volumes of data captured has indicated that the system is required to operate 

beyond the limits for which it was intended. 

Due to the interim nature of the project and provincial fiscal restraint, no 
I attempts have been made to resolve the outstanding problems through system 

^ retailoring or adjustment. Despite the uncertainty regarding further developments 

in this area, it has been agreed that PROMIS does not meet and is not capable of 

meeting the needs of the users in its present form. A system retailoring rnay 
I resolve a number of immediate problems} however, it is felt that there is little 

probability that PROMIS would be capable of handling the volume of data. 

Currently, an effort is underway to initiate a detailed requirements analysis of the 

Office of the Crown Prosecutor in anticipation of future development. Also, the 

initial proposal of integrating PROMIS with the CAP system is being reviewed. 
British Columbia 

Unlike the three previously-discussed jurisdictions, British Columbia had 

. previously developed a series of automated systems to assist various functional 

components Of the Judicial process. Both PROMIS and a custom-built system wculd 

be capable of satisfying the technical requirements of an integrated system. 

PROMIS offered significantly faster Implementation, a proven track record both in 

conversion to a variety of hardware environments and as an operational system, 

and qualified assistance from INSLAW. The lack of an adequate accounting 

function was the only significant disadvantage of PROMIS which was recognizable 

at the time. 
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However, upon examining PROMIS implementations and custom-built systems 
in pther jurisdictions, British Columbia concluded that the expenditure required for 
implementation could be better used to upgrade existing systems and develop new 
custom-built systems. Two major factors contributed to the decision; PROMIS 
would duplicate functions already performed by several of the existing systems} 
and projected operating costs seemed npuch higher than they should be. In addition, 
system response time was generally perceived as poor, and the ability of PROMIS ' 
to handle large Volumes of data was questionable. 



Summary 

The research by CCJS indicates that several general conclusions may be drawn 
from the PROMIS installations in Canada. 

Jurisdictions which have implemented PROMIS generally found that technical 
expertise far in excess of what had been originally anticipated was necessary for 
successful implementation of their projects. Implementation was faster and 
smoother on systems with a hardware environment that was already suppbrted by 
INSLAW. All jurisdictions felt that communication with other Canadian users to 
share expertise and experience would have been valuable. 

All jurisdictions felt that system operating costs and the turnaround time in ad 
hoc reporting were higher than they should be. However, no adequate solution to 
either of these problems has yet been found. 

Some jurisdictions have expressed concern that PROMIS is not user-friendly, 
and PROMIS does not easily handle the volume of data encountered In theliost 
Canadian jurisdictions. 

All jurisdictions felt that PROMIS performs as advertised by INSLAW, and that 

PROMIS met the overall user and technical requirements. 
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3. Prosecutor's Management Information System (PROMIS) 



Notes 



1. Sidney H. Brounstein et al., National Evaluation Program Phase I Summary 
Report! Prosecuti on Management Information Systems (October 1980), p. 23. 










4. BUY OR BUILD? 



There are generally two methods of acquiring applications software: buy a 
pre-packaged commercial system, or build a custom system. 

Pre-packaged application systems are one of the major growth areas in 
commercial computing today. For standard applications such as payroll and 
accounting, a variety of generic packages can be purchased of f-the-sheif and 
installed with little or no modification. Because the same package is used by many 
organizations, each purchaser pays for only a small proportion of the total 
development cost. For standard applications, it is frequently cheaper ahd faster to 
buy a package than tq develop a custom-built system with the same capabilities. 

' ' I! 

On the other hand, if the application is unique, or in low demand, there may 
not be a pre-packaged system available commercially. If the organization owns 
hardware that is non-standard in configuration, an existing software package may 
not fit that specific configuration. If the organization uses a procedure or method 
which is not reproduced in the software package, the procedure must be changed to 
conform to the pre-packaged software; the software must be modified; or a custom 
package must be developed to handle that procedure. 

A major factor in software evaluation is the determination whether a pre- 
packaged system (if available) is suitable for the application, or if a custom- 
designed system will provide a greater return for each dollar spent. This section 
discusses the issues involved in choosing to buy or build a software system, and 
compares the alternatives. This section does not attempt to advocate buying over 
building or vice versa, butrather to indicate the factors which must be Weighed in 
reaching a decision. 
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4.1 MAKING THE DECISION TO BUY 

Commercial software packages can have many advantages and disadvantages. 
Often, whether a feature of the package is an advantage or disadvantage depends 
on the purchaser and the use to which the package is put. 

Age of the Package 

Software packages which have been in existence for some time may be a 
better investment than a newly-released product. The newer software may or may 
not have been adequately tested in the type of environment for which it was 
designed. If the vendor has not done sufficient de-bugging, undetected errors in 
the software can cause the data and information being handled by the system to 
become inaccurate. Occasionally, software packages are released before adequate 
documentation exists, and even before the vendor's staff is prepared to support the 
new product. 

'O'' 

Vendors of established software packages have had the opportunity to benefit 
from previous customer reacition to their product. As a result, the package may 
have been enhanced to meet user demands in such areas as ease-of-use ("user 
friendliness"), performance, reliability, security, and applicability to a specific 
environment. The vendor v^/ill also have acquired experience in the typical 
problems faced by current customers. This experience is reflected in the kind of 
support new customers can expect from the vendor^ In addition, customers may 
have organized formal or ii|,iformal User groups to trade experiences. Written 
documentation is also morfi likely to be complete, accurate, and reflective of the 
user's' needs., ' ■ 

On the other hand, older software products may not take advantage of the 
latest developments in systems and software technology. The fields of hardware 
and software technology are volatile, and development is continually increasing the 
speed and efficiency of gtate-of-the-art automated systems. A new system may be 
more powerful and faster than an older product. The decrease in computer time 
required to run an appliication package may result in both lower operating costs and 
the increased availability of the computer to run additional application packages. 
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Speed of Implementation 

The implementation period for software packages is generally short, allowing 
the benefits of using the system to accrue quickly. However, few pre-packaged 
systems can be installed, turned on, and used without some modification to suit the 
specific environment. Occasionally, the product is designed in Such a way as to 
make this "tailoring" process as simple as possible, but more often no provision is 
made by the vendor in this area. 

The modifications may be major or minor, depending on a number of factors. 
These include whether the original package was a "good fit" (considered to occur 
when the unmodified software does 70 to 80 per cent of what the user requires 1); 
and whether the package was developed on hardware identical to that used by the 
customer. 

In most cases, the time and effort required to perform the necessary 
modifications are grossly underestimated. Implementation involves more than just 
installing the software. A vendor may advertise that a package can be installed 
and running in two days, but this is just one facet of implementation. In may take 
much longer to integrate the new package with the customer's operating 
environment. 



Portability and Expansion 

It is important to carefully investigate the terms of the vendor's standard 
software purchase or lease contraqt. The contract should always specify whether 
the user may copy the software (in order to have a backup copy, or to use the same 
program at a second location), or whether the user must buy additional copies at 
full or reduced cost. The same provisions may also apply to system documentation. 
It should be clearly stated whether the user may make copies of documentation, or 
whether copies must be purchased from the vendor. 






other liceneing or security provisions should also be carefully evaluated The 
vendor may Impose constraints on the use of program code so that the package can 
only be modified on his terms. For example, altering code may be grounds for 
invalidating a maintenance agreement. 

An organization which purchases pre-packaged software should also carefully 
evaluate its own future plans. Does the organization own, or plan to buy, another 
computer? Even ,f the second machine is the same brand-name as the first, the 
machines may be so different that the software designed for one wUl not 
automatically run on the other. If the brand-names are different, conversion may 

prove to be difficult and costly, if not impossible. 

It Is also important to evaluate the future uses of the software package to be 

purchased If the initial Implementation is successful, it is not unusual for the user 

to demand more and more from the package as time goes by. If a pre-packaged 

system only just fits the current needs of the purchaser, then, in a short while, 

urther demands will exceed the producfs capabilities. If a package has features 

and capacity beyond the current need, the user will be able to "grow into" the 

package. If a package that just fits the current need is selected, planning should 

egin immediately for development or purchase of more advanced features or of a 
new system. 

Another factor to consider is the flexibility of the system. Many vendors 

design systems that allow for "customization" (tailoring) by each user. However 

systeT"' wWely from system to 




Design and Compatibility 



A pre-packaged system may attain a greater level of sophistication than a 
similar, internally-developed system. Because the vendor recoups the development 
^osts from a group of licensed users, it is usually possible for the vendor to devote 
mo e resources to refining the system than could any single user. A pre-packaged 
system may be designed to satisfy a wide range of users, however. It may also be 
slower and less efficient than a custom-built system. 



An organization may have branch offices which regularly exchange 
information, or it may be required to report to outside agencies on a periodic basis. 
By selecting pre-packaged software, the organization can ensure that the 
information exchanged is uniform, and that reports are always produced using the 
same format. If each branch or agency uses a different system, it is frequently 
necessary for each to develop expensive "front-end" programs to manipulate the 
format of the information coming from the other members of the group. 

Similarly, if an organization has already automated to some extent, the new 
package may not integrate with the existing system(s). If information must be 
transferred, translation programs may be required to make the existing format 
compatible with the new system. Costs for developing such programs must be 
anticipated. 

Training and Staff Acceptance 

If the new system requires a massive change in work patterns, staff members 
may exhibit resistance to the system for months, or even years. To overcome this, 
it is important to have staff members involved in the evaluation and selection of 
the system from the earliest possible date. Early staff involvement can help to 
reduce post-installation resistance. Training provided by an experienced vendor 
may also reduce the anxiety of staff members who are wary of machines and 
reluctant to give up an overloaded manual system. 

On the other hand, the training provided under contract by the vendor may not 
be sufficient for the staff to make the most effective use of the system. Written 
documehtation may be inadequate to fill in the gaps. The vendor may supply 
further traihing and documentation at a specified cost. If not, the organization 
may find it necessary to write manuals to supplement the documentation provided 
by the vendor, or even to hire an in-house support person to provide extra training 
and ad hoc support to other staff members on a continuing basis. The costs 
involved in training and documentationf whether provided by the vendor or by an 
in-house employee, are factors seldom, considered when estimating system cost. 
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When a system Is purchased without sufficient involvement of the staff in the 
decision, the ■W (Not Invented Here) syndrome ^ may appear. Staff may resent 
having to install, maintain and use a system that was not developed internally 

This feeling can be exacerbated it the package is poorly designed and/or diffic’ult 
to implement. 



4.2 MAKING THE DECISION TO BUILD 

Custom software is written expressly to fit the application requirements of a 
particular organization. The program may be developed using either in-house staff 
or a firm under contract to the organization. 

As with commercial software, there are both advantages and disadvantages to 
building custom software. 



Development Risks and Rewards 

Scheduling 

Through frequent monitoring of the project's progress, the organization can 

keep development time and costs in line by re-arranging priorities, redefining the 

scope of the project, or re-allocating resources, as necessary. Development can 

also be scheduled with a view to hardware availability - either taking advantage 

of alack periods, or freeing the computer during periods of heavy demand by other 
applications. “ 

If desired, the new system can be built in stages. Pressing needs can be met 
first; and it the system is carefully designed, expansion can easily encompass the 
r. s. In fact, with enough forethought, the package can be cpntiniially updated 
and tailored to fit the expanding and, changing needs of the organization, at 
minimum cost. 
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On the other hand, development projects frequently entail a large risk of 
unexpected problems that can cause delays in the schedule. Often, the time 
required for the work is underestimated at the start. Once the project is 

underway, maintaining the schedule depends on many factors. 

If schedule delays become extreme, there is a risk that the final cost of the 
project wUl be more than the resulting system is worth. In fact, projects are often 
cut short for budget reasons, and may never reach a state where they perform all 
of the originally-intended functions. In some cases, time and effort may be better 
spent on tailoring and maintaining a pre-packaged system. 
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Usually (though not always), a custom system costs more than a pre-packaged 

system. Aside from the costs of schedule delays, already discussed, there are other 
costs to be considered. 

To ensure a reasonable level of sophistication in the completed system, there 
must be a blending of programming expertise with in-depth knowledge of the 
organization for whom the system is being developed. Most developers are not 
experts in subject-matter areas. It may even prove impossible to find the 
necessary mixture of expertise. Without this sort of collaboration, the system may 
not be sufficiently flexible to accommodate developments and changes that occur 
in the given subject-matter area^ Major changes may require redevelopment of the 
package, with all developmental costs being incurred once again. 

It IS important to ensure that development is documented as it proceeds. If an 
employee should leave the project before completion and no documentation of 
his/her special knowledge of the system exists, costs are incurred while waiting for 
a replacement to acquire that special knowledge. 



The operating cosh of the system is another factor. A pre-packaged system is 
designed to fit the requirements of as many potential customers as possible. This 
aspect of the system is frequently reflected in slower operating speed and higher 
operating cost. A custom-built system can be streamlined and fine-tuned to fit the 
user's needs perfectly, which usually results in an increase in the operational 
performance and a reduction in the operating cost. 



End Result 

The system which results from custom development is likely to be more 
efficient than a pre-packaged system. The organization can specify the computer, 
the operating system, and the programming language to be used. By designing the 
system around the existing hardware environment, the organization is unlikely to 
underuse existing equipment or be forced to buy equipment which it did not 
previously require. The organization can also specify the design^ development, 

documentation and operating standards it desires. 

The custom-built system can be designed to fit precisely into the 
organization's operational environment. The likelihood of developing a more 
effective system (from the user's viewpoint) increases. The new system can also be 
designed to integrate with and take advantage of existing systems and data bases. 

Staff members often develop pride of ownership in a custom, system, 
particularly if they have been thoroughly consulted during development. This 
proprietary feeling enhances their ability to learn and to use the system profitably. 
The feeling develops not only because the system was developed within the 
company, but also because the system more accurately conforms to the 

organization's methods. The system can be designed to fit the specific needs of the 
end-users. 
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Contracting for Development of a System 

If, instead of using the in-house staff, a software development company is 
hired, there are several important points to consider. The first is the volatile 
nature of the industry. Many small development firms remain in existence for only 
a few years. If the firm goes out of business shortly after the system is completed, 
no external support for the package will exist. Support from that point will depend 
on the amount and quality of written documentation available. 

Another consideration is the ownership of the software. The contract must 
specify who owns, who may sell or license, and who may modify the software. The 
contract should also set out the terms of the acceptance test for the system, as 
well as the type and amount of support to be provided by the developer after 
acceptance. 

4.3 COMPARING THE BUY/BUILD OPTIONS 

When deciding whether to buy or build, the user must consider each factor 
discussed previously, along with the relative weight of each factor. The 
advantages of custom systems may seem few in number, but the relative weight of 
each advantage is high. The advantages of pre-packaged systems are high in 
number, but may be overwhelmed by the relative advantages of the custom system. 
For example, depending on the complexity of the software and how well the 
package fits the required application, the tailoring necessary to implement the pre- 
packaged software may be so intense that the time and effort could be better spent 
developing a custom system. Reduced operating costs (resulting from the increase 
in operating speed and efficiency) may cancel the higher initial development costs. 
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Physical Considerations 

Whether the system is bought or built, it is important to assess the new 
system's impact on existing computing capacity within the host organization. A 
large, detailed system may unacceptably slow other processing on the same 
computer, or may even exceed the computer's processing capacity. It may be 
necessary to redesign the system; to redefine priorities for computer access; or to 
acquire more processsing capacity. 

If the solution is to acquire more processing capacity, a choice has to be made 
between adding another computer of the same type, or obtaining a more powerful 
model. There are usually critical differences among computer models, even when 
they are buUt by the same firm. If a new computer is acquired in the middle of a 
development project j it may be necessary to reschedule or delay the project while 
the system is being adapted to the new machine. Where possible^ hardware 
additions or changes should be anticipated and scheduled into the project. 

Tabular Comparison 

A tabular comparison of the factors to be considered is presented in Table 
4- A: Comparison of Factors in Buying and Building a Software System- 




Table 4-A: Comparison of Factors in Buying and 
Building a Software System 



FACTOR 


BUYING A SYSTEM 


BUILDING A SYSTEM 


Conformity to 
User's Needs 


Software will usually require 
some modifications to adapt 
it to the hardware 
environment or to the 
organization's policies and 
procedures. 


Specifications can be 
designed to meet the user's 
needs perfectly. 




Alternatively, departmental 
policies and procedures may 
require extensive 
modifications to adapt to the 
software. 




Implementation 

Period 


Generally (but not always) 
short. Benefits of using the 
system can accrue quickly. 


Generally (but not always) 
longer than the 
implementation period for 
buying. Initial benefits may 
not accrue quickly. 






However, the custom-built 
software should be m.ore 
efficient than a purchased 
system in terms of operating 
speed; when the system 
becomes operational, the 
benefits of increased speed 
(lower operating costs and 
faster turn-around time) can 
accrue quickly. 


Implementation 

Schedule 

o ■ 


If extensive modifications 
are required, the 
implementation schedule may 
take more time than 
anticipated. 


The system can be built in 
stages to meet pressing needs 
first, then expand to 
encompass the lower-priority 
needs. 



...continued 
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FACTOR 


BUYING A SYSTEM 


BUILDING A SYSTEM 


Contract 

Obligations 


The contract must specify 
the ownership and licensing 
of the package, any 
provisions for back-up copies, 
modifications, installation on 
multiple systems, and 
external support after 
acceptance of the product. 


If the work is performed by 
an independent software 
development company, the 
contract must specify the 
ownership and licensing of 
the package, any provisions 
for back-up copies, 
modifications, installation on 
multiple systems, and 
external support after 
acceptance of the product. 


Modifications 


The contract may restrict or 
prohibit modifications to the 
software. 


There are no restrictions on 
the modifications to the 
software. 




If the vendor subsequently 
updates the software, the 
modifications to the original 
version may be lost. 




Expansion 


The package may not. be 
expandable enough to fit the 
future needs of the users. 


With forethought and 
planning, the system can be 
continually updated and 
modified. 


Transferability 


The contract may restrict or 
prohibit installation of the 
software on other computer 
environments belonging to 
the purchaser. 


On a well-planned system, 
there are no legal Constraints 
on the transferability of the 
software. 


Uniformity 


If several agencies obtain the 
same package, a potential 
will exist for uniform 
information and statistics 
exchange among those 
agencies. 


Generally, each branch of the 
organization will receive the 
same system, thereby 
ensuring uniform information 
and statistics exchange. 






...continued 
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FACTOR 


BUYING A SYSTEM 


BUILDING A SYSTEM 


Age of System 


Older system has proven 
itself; newer system may not 
be sufficiently debugged. 


New custom-built system 
may not be completely tested 
and debugged. 




Older system frequently do 
not take advantage of the 
state-of-the-art technology. 


New custom-built system can 
take advantage of the state- 
of-the-art technology. 


Design and 
Compatibility 


Because the vendor has 
internal expertise and 
experience with other users, 
the pre-packaged system may 
be more sophisticated than 
an internally-developed 
system. 

The system may not 
integrate with existing 
manual and automated 
procedures. ' 


The system can be designed 
to follow the organization's 
exact method of operation, 
and therefore integrates well 
with the existing manual and 
automated procedures. The 
system is likely to be more 
efficient operationally than a 
pre-packaged system. 


User's Group 


A number of Users of the 
package may have organized 
a user's group. 


No user's group exists. 


Training 


Training provided by an 
experienced vendor may 
reduce the anxiety of staff 
members. However, training 
provided under contract may 
not be sufficient for the staff 
to make the most efficient 
use of the system. 


The training period may be 
shorter, because the program 
is designed to emulate the 
manual procedures used 
previously. However, the 
training provided may not be 
as extensive and professional 
as that provided by an 



experienced vendor* 



...continued 
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FACTOR 


BUYING A SYSTEM 


BUILDING A SYSTEM 


Staff 

Acceptance 


Those who operate and 
maintain the system may 
resent having to install, 
maintain, and use a system 
which was not developed 
internally. 


Staff members often develop 
pride of ownership in a 
custom-built system. 


Oocumentatidn 


Written documentation is 
more likely to be complete 
than on custom-built 
systems. 

If documentation is 
inadequate, the purchaser 
may have to buy or write 
additional documentation. 


The documentation 
frequently will be incomplete 
and/or out-of-date. 

The documentation must be 
written, maintained, and 
updated by the developers. 


Development 

Cost 


The cost of the basic package 
is fixed and known. Usually, 
a pre-packaged system costs 
less than a custom-built 
system, because sales to 
several purchasers reduces 
the per capita development 
cost and subsequently the 
price per purchaser. 


The final cost of the project 
must be estimated. The time 
and resources required to 
develop the system are 
frequently underestimated. 

4 


• 


If extensive modifications 
are required, the cost may be 
much higher than 
anticipated. The time and 
cost required to modify and 
install the system are 
frequently underestimated. 


t, 


Operational 

Cost 


The operating costs may be 
estimated from the 
experience of other 
purchasers. 


The operating costs may be 
lower than those of a pre- 
packaged system, because 
the custom-built system can 
be developed for maximum 
efficiency within the user's 
environment. Over a period 
of time, this lower operating 
cost may offset the higher 
development cost. 




4.4 CONCLUSIONS 

The question of whether to buy or to build an automated system may be 
answered only by considering many factors. The relative weight of each factor 
varies according to the specific needs of a particular organization at a given point 
in time. In a few cases^ a commercial package will fit the user requirements 
exactly; in others, there will be no commercial packages available; in most cases, 
commercial software will fit some user requirements but not all of them. Given 
the latter case, the decision must be made to accept the limitations, to attempt to 
tailor the package, or to build from scratch. 

A requirements analysis should take into account each factor discussed in this 
section. This analysis must define the specifications of the system, determine if a 
pre-packaged system exists, estimate the costs (of development, installation, and 
operation), and consider management factors such as the potential of the system 
for future growth and modification, and its impact on the user community. Only 
when the weight of all these factors in each particular situation is considered can 
the buy/build question be resolved. 
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4. Buy or Build? 

Notes 

1. Steven Weinberg, quoted by Carol Tomme Thiel, in "A Shopper's Bonanza", 
Infosys terns , Vol. 28, No. 9, p. 54. 



2. Martin and McClure, "Buying Software off-the-rack", Harvard Business 
Review , Vol. 61, No. 6, page 32. 




5. CONCLUSIONS 





Generally, the PROMIS software product can be adapted to suit the needs of 
the Canadian justice community. However, PROMIS' ability to satisfy the needs of 
a particular Jurisdiction can only be determined by a careful evaluation of that 
jurisdiction's specific needs through a detailed requirements analysis. 

Only when all of the relevant factors have been defined and included in the 
overall cost/benefit equation can a clear distinction be made regarding the 
suitability of the PROMIS software to a specific jurisdiction. 



5.1 BENEFITS OF PROMIS 

PROMIS has a proven track record. The system has been installed in a number 
of American and Canadian jurisdictions with relative success. The vendor, 
INSLAW, provides comprehensive technical assistance (at varying cost) both before 
and after installation. The majority of the purchasers of the PROMIS software 
have been favourably impressed with the on-going support and advice received. 

The ability to tailor the product allows the user jurisdiction to modify the 
basic system to suit its particular needs. The data base, data entry screens and 
editing criteria, inquiry displays, indices, and output formats can all be modified or 
adapted to a greater or lesser extent. 

INSLAW organizes and administers a PROMIS User Group that meets 
periodically in American cities. Users of the PROMIS system can trade 
experiences and knowledge related to PROMIS in various environments. 

In American^ustice-related automation studies, the PROMIS system tends to 
score slightly higher in user satisfaction than other systems. 
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5.2 DRAWBACKS OF PROMIS 



The user must convert, install, and tailor the software system. The conversion 
of PROMIS to a particular hardware environment (whether supported by INSLAW or 
not) requires skilled personnel who are knowledgeable in PROMIS and subject- 
matter concepts, as well as in the policies and procedures of the jurisdiction. 
Without this expertise, conversion can take much longer than generally expected 

PROMIS is not considered to be user-friendly. Existing policies and procedures 
may have to be modified to accommodate PROMIS. Data capture can be a 
complex and cumbersome procedure. In certain installations, terminal response 
time IS slow. Although the system is thoroughly documented through the automatic 
generation of listings, end-user documentation must be written by the user. 

PROMIS is not capable of handling large volumes of data entry on a routine 
basis. 

Compared to custom-built systems, PROMIS systems do not necessarily cost 
less. An American study in 1980 (by Sidney H. Brounstein et al., for the National 
Evaluation Program) found that PROMIS systems cost, on average, about 16.7% 
more to buy, install, convert, and tailor. However, in the same study, PROMIS 
systems tended to cost slightly less to operate. 



5.3 SUMMARY 

The users who were most satisfied witii the automated justice information 
system (whether PROMIS-based or not) were those who matched the needs 
documented in a thorough requirements study to the system they eventually 
bought/developed. In any marketplace, the onus is on the buyer to shop wisely and 

select goods which fulfill a real need. Shopping for software is no exception to this 
rule. 



Appendix A - Justice Information Systems 



The following justice information systems were studied in i979 and 1980 by 
t e National Evaluation Program in the United States and by the National Work 
Group on Justice Information and Statistics (NWG) in Canada. 

P ROMIS - Prosecutor's Mana g ement Information 

PROMIS is designed to track arrests, defendants, charges, cases, court events, 
and witnesses through the Judicial process. A special tailoring package allows the 
system to be adapted, within limits, to the needs of each jurisdiction. PROMIS has 
een adapted to a number of jurisdictions. PROMIS may run on several large-scale 

TroMiT' ’‘stalls on 

C ORPUS - Criminal Oriented Records Pr o duction Unified System (Alam .H» 

County, California) 

CORPUS is an integrated system on a large scale computer with extensive 
data sharing. CORPUS was originally transferred from Santa Clara County, 
California, to Alameda County, but extensive modifications were made to the 

transferred system. CORPUS is the only non-PROMlS transferred system that was 
examined in the two studies. 

PO LITE - District Attorney Automated Leoal I n formation System 
County, California) ~ ^ “ 

DALITE is a prosecutor-dedicated system run on a minicomputer. The 
information can be entered and accessed only by representatives of the 
prosecutor's office. 
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See the general description for CJIC. 




See the general description for CJIC. 



OBSCIS - Offender Based State Corrections Information Systems. 



JAMS - Jail Accounting Microcomputer System. 
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